@sreichel -Thank you for your work on this PR and for your kind words. However, I have some concerns and suggestions based on our previous implementations (PR #4239 and #4969) and on practical usability:

1. The current message is incomplete, as it does not specify exactly where the page is used. Using "Store View" in the message is not informative (and takes precious space), especially since multiple store views can have the same name. My approach displays the logical combination with a defined lord, such as "Default Config, Madison Website, Madison Website > French", making it much easier for users to quickly identify and change the relevant scope immediately (e.g. Store View: French vs Madison Island > French)

2. When changing strictly the URL key, Status, or Delete, there should always be two mandatory messages displayed. First, a warning stating that the action cannot be performed and showing the reason (a short phrase). Second, an informational message explaining concretely where is the place the user can make the change (including the link to Web > Default Pages). If other allowed data was changed, a third success message should be displayed to confirm that those changes were saved (not the one existing which creates confusion and says the page was saved - only the unrestricted fields were salved).

3. Based on our previous discussions and the changes already implemented, this PR should not only address the message shown when deleting a page, but also comprehensively cover all three scenarios: changing the URL Key, updating the Status, and deleting the page.

For the info message displaying where the page is used, I can drop the attempt to build a grammatically correct English sentence (method _joinWithCommaAnd in PR #4969).

I believe these adjustments are crucial for a better user experience, especially in multi-store setups but this PR forces me to close my previous work, even though it could be easily adapted to incorporate these suggestions and best practices.

The current message is incomplete

All is done here, can you make suggestions to the code?

    public static function getScopeInfoFromConfigScope(string $scope, string $scopeId): string
    {
        return match ($scope) {
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_DEFAULT => Mage::helper('cms')->__('Default Config'),
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_WEBSITES => sprintf(
                '%s "%s"',
                Mage::helper('cms')->__('Website'),
                Mage::app()->getWebsite($scopeId)->getName(),
            ),
            Mage_Adminhtml_Block_System_Config_Form::SCOPE_STORES => sprintf(
                '%s "%s"',
                Mage::helper('cms')->__('Store View'),
                Mage::app()->getStore($scopeId)->getName(),
            ),
        };
    }

this PR should not only address the message shown

This PR is ONLY for the message :P

Changes in logic please in another PR.

This is the current implementation in OpenMage. We can immediately notice that the message does not indicate where exactly the page is being used. The entire scope configuration list must be searched until it is found.

This is my implementation. The message clearly indicates where the page is being used. Furthermore, since it could be used in many places, I avoided using “Website” and “Store View” labels to save space. Moreover, the list of locations in parentheses follows a logical order — it fully traverses the tree, for example: Main Website, Main Website > French. If there are multiple stores, they will be listed in their respective order, making it even easier to find. In addition, I point the administrator to the exact location in the Backend where he can edit the scopes.

This is your implementation. It can be seen that you borrowed my idea of showing the scopes where the page is used, but the display is far from optimal — the usage of the words “Store View” and “Website” takes space, and I cannot tell at a glance where I should go (Stores and Websites are not listed in a logical order). In addition, there is no link to direct the administrator to edit the configuration; in my opinion, this is a useful feature.

In conclusion, thank you for taking the time to implement this PR. As I had already been working on a PR for the same functionality and shared my approach earlier, which includes more features, it would have been more constructive to coordinate rather than opening a separate PR and moving in a different direction.

Out of respect for you, I will refrain from reviewing further implementations and, more broadly, from contributing to anything related to the usage of pages in Default Pages. You are free to implement your approach. I will focus on improving my own version as a separate extension, ensuring it does not interfere with the core code and avoiding any conflicting discussions on this topic.

I hope you take all my feedback regarding this issue into consideration, with the request that you see it through to the end. I will focus my attention on other issues in OpenMage. Thank you for your understanding.

In a few words, lets change the wording. I asked for suggestions. Link to config is fine too.

This PR was to avoid working on duplicated functionality for getting usage in config.

?

In conclusion, thank you for taking the time to implement this PR. As I had already been working on a PR for the same functionality and shared my approach earlier, which includes more features, it would have been more constructive to coordinate rather than opening a separate PR and moving in a different direction.

@addison74

• "same functionality" ... this PR is only to improve the error message. You could have opened an issue for it. Your PR added logic thats already in, and this should be avoided.
• "more features" ... changes in functionality should be discussed. Adding link to config section is nice, and already added.
• "different direction" .... You are welcome to work on all cms things, fixing error messages is only a part of it.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

I’ve reviewed again the code and the error message in this PR. Unfortunately, the current error message is not clear enough for users:

• It does not explicitly and logically list all places where the page is used as a default (Home Page, No Route, No Cookies).
• It uses technical config path names that can create confusion.
• It does not provide a direct link to the config section, which would help users quickly resolve the issue.

For a better experience:

• Please display each usage with a friendly, ordered label.
• Include a direct link to the Default Pages configuration section.

@copilot, please provide your feedback regarding the clarity, ordering, and helpfulness of the error message, and whether it should include direct links to the configuration section for easier navigation

@addison74 your AI comments drive me bit crazy ...

It does not explicitly and logically list all places where the page is used as a default (Home Page, No Route, No Cookies).

See screenshot.

It uses technical config path names that can create confusion.

Ummm? Before that PR.

It does not provide a direct link to the config section, which would help users quickly resolve the issue.

See 5ac59d3. Link to config section is there.

Here is my reply:

I understand that you didn't like my answer, but I can say the same thing about the fact that you made me close my contribution to CMS Pages and Default Pages, because "we have to do it step by step". We could have discussed the necessary changes, but you opened this PR without even asking my opinion. No problem I closed mine and I didn't put ethics into question.

I offered you a visual comparison between your implementation and mine. My message is clear, I am pointing where the page is used, you just say Store View: French. Well, if you have 10 stores in French, which of them uses the page? If you consider your listing to be orderly, clear, then please convince the others and do not ask my opinion about this one.

Here is the AI's reply:

There is still ambiguity in the way locations are listed where the page is used as default. For example, if a page is used in a store view named "English", it is not clear which store view is meant, especially if there are several "French" store views across different websites and stores. The listing should provide full context, such as "Website: Main Shop > Store: Europe > Store View: French", not just "French". Otherwise, it is difficult for admins to know exactly where to make the change.

Another important aspect is that listing the full path for each usage (Store View, Website View) can consume a lot of space in the error message area, especially when the page is used in multiple locations. This can make the message harder to read and less user-friendly, particularly for stores with many store views and websites. It would be helpful to optimize the way these locations are displayed—either by grouping, shortening > labels, or providing more compact formatting—so the message remains clear without overwhelming the admin interface.

In conclusion, please consider revising the message to provide a logical, fully-qualified path for each usage, and order them (Default Config, Website, Store, Store View) for clarity.

WTF?

"we have to do it step by step" because you mixed up different thing over multiple PRs.

• error messages should be fixed ... 1 PR
• change logic for changing url key ... 1 PR
• change logic for ... 1 PR

The current error message is bad. This PR targets this. ONLY this. It adds 60 line of code to improve it. I told you multipe time to check code in resource model, to not duplicate functionalty - but you ignored id.

This is why i made the PR!

Please manully test to it to make sure given information in error message are helpful.

Feel free to work on every logic change, i'll do not.

I understand the purpose of this PR very well. You don't need to repeat this to me. If you want my feedback on the last version:

1 - The sentence is grammatically incorrect due to the lack of the article "the". In a technical context the wording may be acceptable, even if it is not grammatically perfect. I would have preferred the message to start like this "You cannot delete this page. It is used in the configuration as: ". If you still prefer a technical version, in Magento style, then you can formulate it "Cannot delete the page. It is used in the configuration as:" or "Cannot delete the page. It is used as a Default Page in the configuration for:

2 - I would not use quotation marks for Store views, also for Home Page, No Route Page, No Cookies Page. It is a tiring visual abuse. Here is a better visual experience.

3 - We do not have a logical order in the message. I have dealt with this aspect. I would have liked to see this order

Default
Main Website
Madison Island > English
Madison Island > French
Madison Island > German

Here is how it would look in the message

(Default Config, Main Website, Madison Island > English, Madison Island > French). In your message Madison Island "French" is before Main Website. You are not going through the tree in order, a real hierarchy in the system, logical for the user's eye.

4 - Default Config and Website Name are correct without quotation marks, but in the case of the combination (Store Name + Store View Name) I would use a delimiter that to show that it is a tree. I implemented a configurable delimiter that allows the use of any sign to make the location as clear as possible. I chose the > character which is clearer and shows the connection between the two.

5 - Being a message that can be crowded it could be put on several lines, for example (if possible)

"You cannot delete this page. It is used in configuration as:

Home Page
Default Config, Main Website, Madison Island > French

No Route Page
Default Config, Main Website, Madison Island > English

No Cookies Page
Default Config, Main Websie, ....

6- The message class must be checked because it is not the same for the both action. For the Delete action it is the correct css message (throwerror), but for the Disable action it not, it add the warning warning class with a grey background. Here is the message for the disable warning.

PS - If you still want to take the implementation for CMS Pages step by step, I would like us to have a step-by-step discussion first in the Discussions section or in private and then move on to the implementation. We risk ending up with dozens of comments again.